Linkerd创始人：Linkerd采用率2022年翻了一番

对于 Linkerd 来说，今年是不错的一年。尽管大部分软件同行都在经济衰退中苦苦挣扎，但 Linkerd 的采用率一直在增长。事实上，日志指标显示使用 Linkerd 的稳定 Kubernetes 集群的数量在 2022 年翻了一番。Linkerd 可能是唯一一个从 CNCF 获得毕业资格的服务网格，但它肯定不会因此放慢增速！

这种增长从何而来，为什么是现在？根据今年与新采用者的交流，我们得出如下看法：服务网格在早期名声不好，这要归咎于对一些项目的极端炒作，因为这些项目相对还不成熟并且复杂。这些早期采用者决定暂缓使用，直到尘埃落定。现在他们回来了，他们正在寻找一个不会让他们背负众所周知的操作复杂性的选择，并且第一次看了这个可能。

他们自然而然地转向了 Linkerd，它以其简单性在服务网格领域独树一帜。Linkerd 的大部分优势都归功于它的数据平面。Linkerd 是唯一一个避开 Envoy 并专注于专用 sidecar“微代理”的服务网格。在 2018 年，这是一个有争议的决定；到 2022 年，这种方法持续得到肯定的回报。当其它项目花时间为数据平面的复杂性和资源消耗构建解决方案时，Linkerd 却专注于提供强大的功能，如多集群故障转移和基于网关 API 的完整 L7 授权策略。

但是 2022 年也没有完全按照我们的预期进行。即使是我们这些头发花白的服务网格老手，也可以吸取一些教训，并且我们在这一年中经历了一些真正的惊喜。以下是 2022 年让我们感到惊喜的一些事情。

— 1 —
惊喜 #1：Kubernetes 的网关 API 非常适合服务网格

到目前为止，我们今年最大的惊喜是 Gateway API，它实际上导致我们在中途改变了计划。就在我们最终确定 Linkerd 的 L7 授权功能时，Gateway API 在年中推出了 Kubernetes Beta 版。当我们更深入地研究这个项目时，我们意识到了几件事：

1. 它已经解决了我们在 Linkerd 2.12 中解决的一个主要问题：你如何在一个全面的、可组合的、但仍是 Kubernetes 的方法中描述一个 HTTP 流量类（例如“一切以 /foo/ 开头”或“一切有这个 header”）？

2. 与我们不情愿地计划添加到 Linkerd 来执行此操作的 CRD 不同，Gateway API 资源已经是 Kubernetes 的一部分。

3. 它的设计很好。真的很好。虽然它最初设计用于处理入口配置，但核心原语非常灵活且可组合，因此它实际上也适用于服务网格用例。

所以我们打消了原来的计划，转而采用 Gateway API 作为 Linkerd 授权策略的核心配置机制。尽管这会将 2.12 的发布推迟几个月，但我们知道这对 Linkerd 的采用者来说是正确的。

这个决定已经奏效了。在即将发布的 2.13 版本中，我们正在利用 Gateway API 资源类型来实现基于 header 的路由和可配置熔断等功能。Linkerd 还参与了 GAMMA 计划，这是 Gateway API 中的一个项目，旨在更好地获取服务网格用例。

— 2 —
惊喜 #2：eBPF 是一种优化，不是游戏规则的改变者

当围绕服务网格的 eBPF 的讨论在今年年初达到顶峰时，我们决定进行更深入的研究。我们发现的结果不如我们希望的那么引人注目。虽然 eBPF 可以简化一些基本的服务网格任务，例如转发原始 TCP 连接，但如果没有用户空间组件，它根本无法处理 HTTP/2、mTLS 或其他 L7 任务，这意味着它不会提供根本性的改变——即使使用 eBPF，服务网格仍然需要集群某处的 L7 代理。

尤其是备受吹捧的“无 sidecar 的 eBPF 服务网格”模型，感觉像是在可操作性和安全性方面的重大倒退。通过将该逻辑转移到每个主机的 Envoy 代理中，混合节点上的网络问题和 TLS 密钥材料，它们打败了我们之所以首先考虑容器化的大部分要点。eBPF 不需要每个主机的方法，我们很失望地看到营销材料将两者混为一谈。

未来，我们确实计划研究 eBPF，以此作为简化 Linkerd L4 功能集的一种方式，尽管将关键代码转移到内核中的前景让我们感到不安，因为在内核中调试、观察和推理要困难得多。（更不用说eBPF 新引入的令人兴奋的攻击向量了。）

总的来说，我们对 eBPF 的调查并没有真正相信 eBPF，但我们比以往任何时候都更加相信，出于操作和安全原因， sidecars 仍然是服务网格的最佳模型。

— 3 —
惊喜 #3：环境网格

无 sidecar 的 eBPF 服务网格很快就加入了 Istio 的无 sidecar 的“环境网格”模式，该模式结合了每个主机和每个服务的代理。深入研究这种方法对我们来说是另一种学习经历，我们很高兴看到，至少在这里，安全性更好：例如，单独身份的 TLS 密钥材料在单独的进程中维护。

然而，移除 sidecars 的权衡是陡峭的：需要大量新机器，结果具有重要的限制以及对性能的重大影响。

总的来说，结论是生命周期管理和资源消耗方面的改进并没有在 Linkerd 的案例中得到体现。我们的感觉是环境网格比其他任何东西更能解决大规模运行 Envoy 的问题。

— 4 —
非惊喜 #1：容器排序仍然是 Kubernetes 的弱点

除了惊喜之外，我们在 2022 年还看到了一些意料之内的事情。与往年一样，Linkerd 的采用者继续与 Kubernetes 长期存在的问题作斗争——缺乏对容器排序的控制。这表现在多种方面：

• 需要网络访问的 sidecar 容器需要一种在 linkerd-init 容器之后运行的方法

• 终止的作业需要一种方法来向其代理组件发出终止信号

• 重新启动或添加到现有集群的节点需要一种方法来暂停 Linkerd 的网络初始化，直到 CNI 层初始化之后

• ……
  

这些问题中的每一个都可以在特定情况下解决，但一般类别的问题仍然是服务网格采用者的麻烦，并且最严重地违反了我们的原则，即服务网格应该对应用程序透明。然而，随着臭名昭著的sidecar KEP 逐渐消失，我们可能不得不忍受更长的时间。 

虽然，关于另一个 KEP 的谣言四起……

— 5 —
非惊喜 #2：安全性仍然是采用 Linkerd 的首要驱动力

与往年一样，采用 Linkerd 的主要驱动力仍然是安全性。Linkerd 的零配置双向 TLS 一直是该项目的一大亮点，今年引入的 L7 授权策略完善了 Linkerd 的零信任功能集。

我们也很高兴看到市场日益成熟的迹象。几年前，“我们需要传输中加密”是采用 mTLS 的主要理由。在 2022 年，我们听到许多采用者反而说，“是的，我们需要传输中的加密，还需要使用真实工作负载身份进行身份验证，并在每个 Pod 上进行零信任授权”。零信任正在获得真正的牵引力已经不是什么秘密了，如果不是零信任原则的直接实现，基于 sidecar 的服务网格也算不了什么。sidecar 模型再得一分！

和往常一样，我们也尽量保持家里干净，Linkerd 出色地完成了年度安全审计。

— 6 —
2023 年服务网格会发生什么？

明年有望成为 Linkerd 又一个标志性的一年。我们已经计划了一些令人难以置信的兴奋的事情，从即将发布的带有基于 header 的路由和熔断的 2.13 版本到我们目前保密的其他一些杀手级想法。一如既往，我们将专注于保持 Linkerd 简单、轻便和安全。

推荐阅读：

---

分布式实验室策划《Rust实战集训营》正式上线了。这门课程通过40个小时线上直播，10个练习项目，60天课后辅导，把Rust知识讲给你，和你一起从入门到进阶。培训重实战、重项目、更贴近工作，边学边练，点击下方图片可了解具体内容。